Release 10.1A: OpenEdge Development:
Progress 4GL Handbook

General trigger considerations

In general, a schema trigger procedure or session trigger executes within the larger context of the procedure containing the statement that causes the trigger to fire, just as if the procedure or block of code had been run following the triggering statement. Keep the following considerations in mind about how triggers operate:

Progress does not allow database triggers on events for metaschema tables and fields (which have an initial underscore in their names and a negative internal file number in the schema).
You cannot delete a record in a buffer passed to a database trigger or change the current record in the buffer with a statement such as FIND NEXT or FIND PREV.
An action within one trigger procedure can execute another trigger procedure. For example, if a trigger assigns a value to a field and you have also defined an ASSIGN trigger for that field, the ASSIGN trigger executes. You must take care that this does not result in either unwanted conflicts between the actions of the triggers or a possible loop.
By their nature, triggers are executed within transactions (except possibly for a FIND trigger). Whatever action is encoded in the trigger becomes part of the larger transaction.
For all blocks in a database trigger, the default ON ERROR handling is ON ERROR UNDO, RETURN ERROR, rather than the usual Progress default of ON ERROR UNDO, RETRY. You learn more about the ON ERROR phrase in the next chapter.
You can store collections of precompiled Progress procedures in a single file called a procedure library. If you collect together your application’s schema triggers into a procedure library, you can use the –trig startup parameter to identify either the name of the procedure library for triggers or the operating system directory where they reside. See OpenEdge Deployment: Startup Command and Parameter Reference for more information.
When you dump and load database records, you might want to disable the schema triggers of the database, both to avoid the overhead of the triggers and to deal with the likely possibility that integrity constraints enforced by the triggers might not be satisfied until the database load is complete. See OpenEdge Development: Basic Database Tools for more information on disabling triggers.
For information on how SQL access to your database interacts with 4GL schema trigger procedures, see OpenEdge Data Management: SQL Development .

In the following chapter about transactions, you’ll learn how Progress uses locks to control multi-user access to data, and what the scope of those locks is relative to the transactions they’re used in.